這系列文從 Day 1 開始，我介紹最近幾年從 PM 踏入資料領域的經驗。dbt 非常適合給像我這種非技術背景的資料人使用，且提供使用的心態。dbt 是 Tristan 創立 Fishtown Analytics 時開發的產品，為了讓資料人可以像工程師一樣工作 🛠️，他寫在這篇文章 Goodbye RJMetrics, Hello Fishtown Analytics 中。

但是，既然是非技術背景的資料人，不禁想到「像工程師一樣工作是什麼意思？」讓我們來討論一下吧 🎣

為什麼要師法軟體工程師? 🤔

Tristan 在這篇文章 Building a Mature Analytics Workflow 解釋得很清楚。我想特別提到這段：

Most of the problems with the current analytics workflow aren’t so bad if you’re working alone. You know about all the data available to you, you understand its significance, and you're aware of its creation process. But scaling becomes a challenge. As soon as your analytics needs grow beyond a single analyst, these problems start to manifest.

如果你是一人資料團隊，大部分的分析工作沒什麼問題，你知道所有資料、你了解意義，也知道是怎麼處理的。但團隊一但擴大，多人協作就會開始產生問題。

當我第一次使用 dbt 的時候，我就是那個一人資料團隊。雖然有資料工程師會幫我檢查 SQL 程式碼，但他就是看程式有沒有寫錯，不會檢查商業邏輯。只要這段程式跑得動沒有錯誤，就過關了，沒有檢查產出的資料是否正確。所以，當時我對於上面這段話不是很理解，以為有在使用 GitHub 跟 VSCode 就叫做效法軟體工程師 🤷‍♀️。

第二次使用 dbt 的後，資料團隊不只我一人，還有一位資料工程師跟一個剛從營運專員轉成資料分析師的同事。資料工程師當然是知道軟體工程師怎麼工作，但我們都獨立分開處理各自的 data models, 只是共用同一個 GitHub 專案。

當 data models 開始變多，發現大概有 80% 都重複一點，差一兩個欄位這樣。我們才發現 code review 不能只有 review 程式碼是否跑得動，需要了解商業邏輯，互相理解彼此的 data models, 才能共同發展 data models, 討論商業邏輯轉化是否正確，這些知識才能被分享，也才能支援彼此的工作。

那該怎麼解決這個如何協作的問題呢？學軟體工程師！👨‍💻 他們已經解決這題

Indeed, the playbook for solving these issues already exists within our software engineering teams.

The techniques that software engineering teams use for collaborative, rapid creation of quality applications can also be applied to analytics.

這題解法已經有了，就在軟體工程團隊的工作方法中。他們的協作、快速迭代又能確保品質的工作方法，也適用於分析工作。

新職稱 ✨ Analytics Engineer ✨

dbt 也發明了一個新的資料職稱：Analytics Engineer. 推薦這篇文章將 analytics engineering 的由來寫得很清楚：What is Analytics Engineering? 🌟

My role underwent a significant transformation. Finance and marketing teams could generate their own reports. My typical day involved preparing data for analysis by writing transformation and testing code, coupled with thorough documentation. My tools transitioned from Excel and Looker to iTerm, GitHub, and Atom.

So, was I still a data analyst?

我的工作內容不只是產生報表。財務跟行銷團隊都可以自己產生報表。我每天的工作主要是轉化商業邏輯為程式、測試程式碼以及寫文件。我使用的工具不只是 Excel, 還會使用 iTerm, GitHub 還有 Atom.

所以，我還是個資料分析師嗎？

我在 Day 5 有介紹過這個新職稱。雖然在小公司，不太可能每個職位都有一個人專職負責，但光是知道有 3 個工作內容需要調配 🎩，就很有幫助。

如何工作的像個軟體工程師? 🤔

對真正的軟體工程師來說，這很自然 😆，可能覺得沒什麼。以下是我覺得跟 PM 工作不同的地方：

直接討論程式碼 👨‍💻。以往我們比較會寫下問題來討論，或者就當面交流，但發現直接在程式碼留言討論，看著整個情境討論更有效。心態上像是看著證據說話，避免模糊的對話，例如：我覺得這個 XX 概念怪怪的，不太理解，因為可將 XX 概念直接寫成程式碼。

為了做到這樣，我們發現不能在本地開發的差不多才丟到 GitHub, 那時候討論已經來不及，也不方便。才知道，原來 draft pull request 這個功能是有用意的，原本只用基本功能都沒有發現，更早在開發時就將程式碼上傳更有幫助。

我們在一開始使用 dbt 就有安裝 dbt-project-evaluator. 可是因為其實看不懂 warnings 警告跟 errors 錯誤的差異，反正 models 有跑出來就當作沒看到 😦。一直到終於看懂這是什麼意思後，才發現這些檢查背後的條件真的是前人的經驗累積 🧠，不管你最後有沒有要採用，都值得一條條拿出來思考。

How to review an analytics pull request ? 如何 Review 分析的 PR？提供很清楚的指南。身為 analytics engineer, 我們將商業邏輯轉換為程式碼，因此在檢查程式碼的時候，不只要檢查程式本身是否正確，也要檢查商業邏輯是否合理。最後，我們建立了 PR template 作爲提示，提醒我們每次送出 PR requests 要注意哪些。我們也會持續討論跟調整這些 template 🌱.

最後，還有一些工具可以使用。既然在這個新職稱內也有個「工程師」，我們也熱愛採用新技術。例如，我們有使用 SQLFluff 來更正 coding styles. 在 Day 7 內有提到更多工具。

讓我們採用更多軟體工程師的好方法吧~ 🚀

新章節 📖

接下來，讓我們進入新章節，我想介紹 dbt 社群。加入社群後，有很多有趣好玩的事情，希望你可以加入 dbt community! 一起來玩~ 🤗

對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加